Snowbird wrote:


>
> What can happen -- what's happened to us -- is that the tower
> controller doesn't worry his head about your flight plan.

Yes, but it has to be typed in and accpeted by the computer. At all the
class C airspaces all the controllers work all the positions at various
times thru the day. You don't drop a handwritten strip down the tube
and expect the radar controller to handle it.


He
> figures the tracon's gonna vector you and the center's gonna
> reroute you anyway so why should he sweat. He says "cleared
> as filed".

The tower guy says cleared as filed if the strip tells him to say
cleared as filed.


Now you're handed off to Tracon, and he looks at
> your flight plan and realizes he has no clue where you're going.

Have that happen a lot. And the location identifier book is all the way
over there. So you say resume own nav and see where he goes. If I want
to nail it down to 50% of the sky I'll look at the final altitude and
see which way he's going.


> But he figures you'll be out of his airspace before he sorts
> it out, so let the center controller sweat it. He queries,
> "Grumman 12345, say on-course heading", you respond, and
> that's sufficient for him. 10 minutes later, you're handed
> off to Center.

Yep, do that too if you're a slow mover and there's traffic.


>
> Well, the next Center isn't going to be fobbed off with
> "on-course heading blahblahblah" on the handoff, so the buck
> stops with the first Center guy (this is our experience, mind,
> YMMV).

The center has the same route on his strip as I have on mine. He will
move you for traffic, not because he doesn't know where you're going.

So if Newps
> (sorry
> to pick on him) transposes two numbers and has you headed in the
> opposite
> direction than you intend to fly, no one will know until you take off
> from a non-towered airport headed west with the controller having
> carefully
> arranged your separation believing you're headed eastbound.

No controller looks at a set of lat/lons and says to himself..."Flying
east today." A lat/lon is for the computers benefit, it has zero value
to a controller.

"Snowbird" > wrote in message
m...
> "Stan Prevost" > wrote in message
>...
>
>
> I did not intend to assert that only H-class VORs are likely to be
> recognized nationwide -- that's not true. It seems to vary from
> center to center. Any VOR on an airway is a fairly good bet some
> places.

<big snip>

OK, I see that I interpreted your comments about H-class VORs too broadly,
and I now understand your meaning better.

>
>
> > It would seem
> > logical to me (for whatever that has to do with anything) that any VOR
used
> > to *define* airways, low- or high-altitude, would be recognized by any
> > computer that has anything to do with flights on the airway structures
of
> > the National Airspace System.
>
> My husband would say something like "Stan, this is the federal
> government.
> You're expecting it to be logical. There's your mistake. There's
> where
> you're going wrong". (since he rassles federal regs for a living, he
> has a right to an opinion).

:-) Yep, but you will notice that my parenthetical remark disclaimed the
application of logic to a gov't system.

>
> What I *think* is going on, though, is that the airway itself is
> understood
> by the computer, but the specific navaids which define it in, say,
> ZKC airspace, might be unknown to the computers in Miami Center. So
> if
> you route by airways, you're gold, but if you pick a non-H class VOR
> two centers away as one of the few waypoints defining a direct route,
> it might not be recognized even if it's on an airway.
>
> I await further enlightenment on this point.
>

Me too!

The first thing is to understand the controller's needs for route
definition, specifically for a direct flight for this discussion. One might
expect that the controller would be concerned only with the route through
his airspace, so he couldn't care less about the route definition way down
the line. Does he need to be able to make my course line appear on his
radar scope all the way through his airspace? Or does he just need a
short-term projection of my track using radar for present position,
direction, and speed? Probably one need is to be prepared to handle radar
failure. In nonradar procedures, I think they try to move us all onto
airways, and to do this, the panicked controller needs to know which airways
to move us onto that keep us going in the proper general direction and out
of his airspace (or maybe the computers suggest new airway routing). So how
does knowing one VOR-based fix in his airspace do that? Does he have his
computer draw a line on his scope from present position through the fix, so
that he can then pick airways that approximate that route?

The next thing is to understand what the ATC computers are capable of and
how much variation there is among them, in terms of storage/knowledge of
fixes.

But eventually, no matter how well we understand those things, we will come
back to the old oft-debated issue of no matter what you file, you will get
something different or will get major reroutes, so you might as well file
direct airport to airport. I am sure this is more true in some areas than
others, based on my own experience, and for frequently-flown routes, one can
eventually learn reliable routing. Up through the northeast corridor, I
always get reroutes. In the east-central US, I can file from Alabama to
northern Lower Michigan airport-to-airport direct and always get cleared as
filed with no reroutes. I do this frequently. Many times, flying to other
destinations, I have tried to tweak my route to include some major VORs,
only to get an in-flight clearance direct to destination airport.

> > 3. Newps said that his FDIO won't accept intersections that are not in
his
> > center's airspace, but that filing through DUAT/S and AFSS does not have
> > that limitation. I would expect that virtually all general aviation IFR
> > flight plans are entered via DUAT/S or FSS, excluding local clearances
to
> > punch through a layer or for instrument practice. And back to Sydney's
> > comment quoted above, I don't know what she means by the "originating
ATC
> > facility".
>
> I apologize for being unclear. I wasn't talking about filing a flight
> plan. As you say, that's usually through FSS or DUATS. DUATS will
> accept
> a flight plan direct from an obscure intersection in CA to an obscure
> intersection in FL. So will FSS as far as I know (I haven't tried).
> Duats will insert one lat-long per center. FSS doesn't seem to.
>

When I file through DUAT, it doesn't do one lat/long per center, it only
does the final fix.


> What I mean by the "originating ATC facility" is the ATC facility you
> talk to after you leave the ground, or the first Center you talk to.
>

Thanks, I understand your reference now

> > Or maybe she means the center through which the
> > flight plan is routed for processing after it is filed, and I really
don't
> > know what happens there.
>
> That's what I mean. I really don't know what happens there, I
> just know what happens to me :).
>
> Now if you've filed airway routing, I'm told an unrecognized
> intersection or waypoint at the end of the route is no big deal.
> The flight plan gets processed to the unrecognized point. The first
> controller will know which way you're going, and by the time it
> matters, the ATC computer will recognize it. Which is why Don Brown
> and some others favor airway routing, and I have to say I'm
> coming around to that viewpoint myself.
>
> It's mostly an issue if, like many pilots these days, you file
> GPS direct but feel you're making the skies safer or your karma
> cleaner or something by adding the IAF from which you plan to shoot
> an approach to your route. Or, let's say you've read the AIM and
> you virtuously add a waypoint defining your route within 200 nm
> of each center boundry. Let's say it's a VOR.
>

<big snip>

I don't see any difference between filing airport-IAF-airport vs
airport-airport, in terms of fix recognition and controllers knowing your
route. If the IAF (or other nearby fix) is there, it likely won't be
recognized by a distant computer (another center's airspace). But neither
will the airport. Maybe some airports are in all computers, but going into
Podunksville Muni, forget it. "N8158Y, say on-course heading." (Having
lat/long in the flight plan for the final enroute fix or for the destination
doesn't seem to change getting the heading request.) In either case, at the
originating end and along the way, the controllers will be in the dark about
your route, but the situation resolves itself as the flight nears its
destination.


> What can happen -- what's happened to us -- is that the tower
> controller doesn't worry his head about your flight plan. He
> figures the tracon's gonna vector you and the center's gonna
> reroute you anyway so why should he sweat. He says "cleared
> as filed". Now you're handed off to Tracon, and he looks at
> your flight plan and realizes he has no clue where you're going.
> But he figures you'll be out of his airspace before he sorts
> it out, so let the center controller sweat it. He queries,
> "Grumman 12345, say on-course heading", you respond, and
> that's sufficient for him. 10 minutes later, you're handed
> off to Center.
>
> Well, the next Center isn't going to be fobbed off with
> "on-course heading blahblahblah" on the handoff, so the buck
> stops with the first Center guy (this is our experience, mind,
> YMMV).
>
> This is when we, as pilots, get to learn by trial and error
> which waypoints and airports aren't recognized by different
> Center ATC computers as the controller says "um, Grumman 12345,
> can you give me the lat-long for India One-Twelve, or a VOR near
> it? No, I don't have that one...can you give me a VOR on
> your route of flight, within my airspace?" Needless to say,
> if ATC is busy, this totally lacks amusement value for them.
> If ATC isn't busy but the wx is challenging, it lacks amusement
> value for us.
>
>
> > One would think that the DUAT/S systems
> > were designed to only transmit flight plans to centers that would be
> > acceptable to centers, in terms of recognizability of waypoints.
>
> There you go, expecting the federal government to be logical
> again. That's where you're going wrong. That's your mistake. :)

Yeah, there's that logic thing again. But, joking aside, I really do expect
that the DUAT/S contractors operated to an interface specification of some
kind in designing their systems, and do not output data that will not be
understood by the receiving computers.

> > It seems to me that a US pilot filing domestic IFR through DUAT/S or FSS
is
> > safe using any valid identifiers s/he wishes, in terms of having the
flight
> > plan accepted and properly processed by the NAS computers.
>
> What do you mean by "safe", Stan? (see above)
>
> If you mean, ATC will understand which direction you're going and
> how your route is defined provided you use any valid identifiers
> accepted by FSS or DUATS, IME that's just not so.
>

Perhaps a poor term, but I meant it as I said, that the flight plan will be
accepted and properly processed by the NAS computers. To clarify my
meaning, I understand that the flight plan is routed from DUAT/S or FSS to
the center computer having jurisdiction over the departure point. That
machine looks at the proposed route, applies some secret algorithms and
decides whether to accept the route or to discard it and generate a new
route, maybe a preferred route. I meant that a flight plan accepted by
DUAT/S or FSS will not be rejected by the center computer because of an
unrecognized waypoint.

It may be the case that this computer that processes proposed flight plans
is completely unrelated to those that assist (?) controllers move airplanes.
It may be the case that the former has a complete database and the latter do
not.

I'm obviously doing a lot of guessing here, but we ought to be able to
reconcile things. FSS and DUAT/S plans do not get rejected because of
unrecognized waypoints, but all of us have experienced that enroute
controllers do not have access to a complete database. That suggests two
separate systems.

Stan

I'm replying to my own thread rather than starting a new one on the same
topic.

I went back to the "Must File To An IAF" thread and excerpted some
statements that are relevant to the issue I am trying to clarify through
discussion here. I'm not picking on or challenging anyone and I am not
debating filing to an IAF. I am trying to understand the more general issue
of how are fixes/airports/navaids/waypoints handled in various computers
associated with flight in the US National Airspace System, and how pilots
can file flight plans that suit their needs as well as the needs of ATC,
while understanding why.

First I will present the excerpts and then present my questions.

Sydney:
Fact: filing a flight plan to a fix not in the computer database of
the originating facility will cause the computer to stop processing
the flight plan. then the controller has to sort it out. This is
particularly a problem if the pilot has filed "direct" and ignored
the AIM suggestions about including navaids in each center's airspace
on their direct routing.

Newps:
There's no sorting out. If the flight plan comes out of my strip printer
then the computer won't have a problem with it.

McNicoll:
Unless the IAF is also part of the enroute structure it is unlikely to be
stored in the flight data processing computer. Filing one will cause your
flight plan to be rejected at some point, until someone corrects it by
removing the filed IAF!

Sydney:
If the IAF is not an H-class VOR, it's not likely to be in the ATC
database of the originating ATC facility if you're making a trip of
any duration, so filing to an IAF only bolixes the works.

McNicoll:
The IAF is probably an LOM that is not stored in the computer so filing it
will cause the flight plan to stop processing at the last good fix.


Sydney:
But it's still not necessarily a good idea to file to an IAF, since the ATC
facility where the flight originates may not have said IAF in their
database.


McNicoll:
In most cases where the IAF is not part of the enroute system the flight
data processing computer will not accept it anyway.


Sydney:
If you're not filing via airways, and your flight originates outside
the ATC facility who "owns" that IAF, the harm is that the ATC computer
will very likely not recognize that IAF and will stop processing your
flight plan at that point. So if you insist on putting an IAF in
block 8, make sure there are several more nationally-known waypoints
defining your route of flight.


Some general themes running through the above comments and other
discussions:

1. A flight plan may contain fixes that are valid but may not be recognized
by the computers at various ATC facilities along the route of flight.

2. A flight plan containing any valid fixes can be successfully filed
through FSS or DUAT/S but not necessarily by a controller, whose computer
may not recognize some of the fixes.

I believe it to be the case that a flight plan filed through FSS or DUAT/S
is routed to a center computer, which processes the flight proposal using
secret algorithms and decides whether to accept the plan or to generate a
new route (such as a preferred route), and then sends the flight plan to the
ATC facility responsible for the point of origin of the plan, where a flight
proposal strip is printed. This strip will have the information to be given
to the pilot in his/her clearance, and whether it is "as filed" or "full
route clearance". The clearance will include all fixes in the route,
whether or not they are stored in the computer of the initial ATC facility.
Once the controller at the initial facility "departs" the flight, flight
progress strips are then printed out down the line along the route of flight
at the facilities to which the aircraft will be handed off to. Those strips
also include the route, or at least the route information is accessible to
the controller in the computer, whether it is "understood" by the computer
or not. I hope this is correct so far.

Another theme running through the previous comments is that the computer at
each ATC facility along the route does some kind of processing on the flight
plan, but upon encountering a fix that is not in its database, will "stop
processing" at the last recognized fix. This supposedly results in somehow
bollixing up the works. I think it is being said that the controller will
be unable to determine the route of flight through his/her airspace, and
some examples of actual experience were given to illustrate that. Steven
even said the flight plan will be "rejected at some point" until someone
removes the offending fix (which is valid but unrecognized). Newps said
that if it prints on his printer, the computer won't have any problem with
it. I'm not sure how to reconcile those two statements, they could suggest
that an unrecognized fix will cause a flight progress strip to not print
out.

Well, I really don't understand. First, I don't know what kind of
"processing" is performed by the ATC computers, and I don't know what is
meant by "stops processing" or "rejected". When the computer *successfully*
processes the plan, what is different from what happens when it "stops
processing" at some point? Does something different show up on the radar
scope, does an error message occur, are F-16s launched against the offending
aircraft, or what?

Further, I don't understand why, in the previous thread, the emphasis was
placed on enroute fixes (in particular, an IAF) not being recognized by
computers along the way. If the fix were omitted, then wouldn't the same
problem arise with the destination airport? Why is it not the same
situation with just GPS airport-to-airport direct, with no enroute fixes?
Do all the computers store all the airports? I know that when I file direct
to Podunksville Muni several centers away, nobody along the route seems to
have any idea where that airport is, but nothing is bollixed up. Maybe that
is because I generally file through DUAT, and DUAT includes the lat/long of
the airport and the computers can process that. If I include an arrival
fix, DUAT puts in the lat/long of that fix rather than the airport. I don't
know if FSS inserts lat/long like DUAT does.

I performed an experiment with DUAT. I filed (and deleted) several flight
plans, from an airport in Memphis Center airspace to an airport in
Minneapolis Center airspace, with Indianapolis and Chicago center airspace
in between. This is a flight I commonly take, usually GPS
airport-to-airport direct, with no problems (that I know about).

a. Airport (ZME airspace) direct airport (ZMP airspace). DUAT inserted
lat/long of destination airport in route.
b. Airport, VOR in Minneapolis Center airspace, airport. DUAT inserted
lat/long of the VOR.
c. Airport, VOR in Indy Center airspace, airport. DUAT inserted lat/long of
the VOR.
d. Airport, VOR in Indy Center airspace, VOR in Minneapolis Center
airspace, airport. DUAT inserted lat/long of the VOR in Indy Center
airspace.
e. Airport, VOR in Memphis Center airspace, VOR in Indy Center airspace,
VOR in Minneapolis Center airspace, airport. DUAT inserted lat/long of the
VOR in Indy Center airspace.

Assume that any of the ATC computers along the route can process a lat/long,
and that ATC computers store only fixes within their center's airspace. Then
any of these flight plans would have been fine for Memphis Center (and
presumably approach control facilities delegated Memphis Center airspace).
I say that because the computers in Memphis Center airspace would have a
recognized waypoint (lat/long) farther along the route to allow computation
of the route through Memphis Center airspace. I'm not so sure about
subsequent facilities. For example, in Chicago Center airspace, the
adjacent airspace areas are Indy Center and Minneapolis Center. In Cases c,
d, and e, there would be no recognized waypoint or lat/long in Chicago
Center airspace or beyond it. This one experiment suggests that DUAT
generates flight plans that favor the ARTCC in whose airspace the flight
plan originates.

So I reversed the route and reran the experiment.

f. Airport (ZMP airspace) direct Airport (ZME airspace). DUAT inserted
lat/long of destination airport in route.
g. Airport, VOR in ZMP airspace, Airport. DUAT inserted lat/long of
destination airport in route.
h. Airport, VOR in ZMP airspace, VOR in ZID airspace, VOR in ZME airspace,
airport. DUAT inserted lat/long of VOR in ZID airspace.

This supports that the DUAT plans favor the originating ARTCC.

I repeated the experiment on DUATS. For Case a, the result was identical.
For Case e, DUATS did not insert ANY lat/longs. That's all I ran.

(Another difference noted is that DUAT would not let me have more than one
flight plan on file using the same A/C, airports, and times. DUATS had no
problem with it.)

It would be useful to know more about the capability of center and approach
control computers in terms of their databases of fixes. Do they all store
some subset of the total database, and is the way the local database is
constructed uniform across facilities, or is it variable because of
equipment, or local policy, or what? What will work for all of them,
besides lat/long? Have to be careful about putting too many lat/long or FRD
fixes to define the route, because Newps says they "fix" those kind of
flight plans when they see them, or not enough because Steven says that
offending fixes (IAFs at least) are removed.

What I would conclude from my experiment is that whenever going from Fix A
to Fix B crosses one or more center boundaries, including the lat/long of
Fix B will always work, no matter how many center airspaces it crosses.
This might be somewhat tedious to determine. The AIM recommendation to
include at least one waypoint in each center airspace would also seem to
work, although DUAT/S does not do that. I also wonder the reason behind the
AIM recommendation that a waypoint be no further than 200 nm from the center
boundary. Maybe that has something to do with the rules for selecting fixes
to be stored in a center's computers, that it stores fixes within its own
airspace plus 200 nm around it?

I can easily see that pilots might have different experiences depending on
what service they used to file their flight plans.

Any help in getting this sorted out and understood will be appreciated.

Regards,
Stan

Thanks for the great reply, right on target. I would like to inquire a bit
further.

"TJ Girl" > wrote in message
om...
> Hopefully this will clear a bit up...
> The Center's computer contains a subset of fixes that includes all
> within that center's boundaries, a lot of the adjacent center's fixes,
> and the major fixes nationally.

Can you shed any light on the rules for including fixes from adjacent
centers? Is it everything within 200 nm of the center boundary? Or just
airway VORs?

However, any center's computer can
> understand a latitude/longitude location.
> In order to "process" a flight plan, the center must understand the
> route up until the first fix outside the center. This is why a lot of
> controllers will put in the flight plan "route..lat/long..fix at that
> lat/long" - here the host (Center) computer only processes up to the
> first lat/long and doesn't care what comes after it, so the unknown
> fix can be included without a problem. Many controllers also just put
> a nearby major airport as the destination and put the real destination
> in the remarks, then a controller in the destination center, or maybe
> one adjacent to it, can put in the correct destination.
> As far as processing, this means that the computer "knows" where you
> are going. The controller can display route lines. Your target will
> flat track instead of free track - which means the computer predicts
> your future position based on flight plan data, instead of just your
> history. You can auto-hand to the next sector - which means the
> computer will start the handoff at a specified distance from the
> sector boundary if the controller has not already initiated it. It
> means things like conflict alert will be more accurate, because the
> computer knows where you are expected to go and is not just guessing
> based on where you have been. Basically, it just comes down to
> meaning the computer (and therefore the controller) know what you are
> going to do.
>

What does the computer do if it cannot process fixes to determine the route?

>
> > Do all the computers store all the airports?
>
> They don't store all, but will store all the major ones, so it really
> just depends where your destination is.
>

Is there a simple rule for what constitutes a major airport for this
purpose?


> > Do they all store
> > some subset of the total database, and is the way the local database is
> > constructed uniform across facilities, or is it variable because of
> > equipment, or local policy, or what?
>
> They store a subset, as mentioned above. The theory is space
> limitation. The new URET system stores the entire Jeppesen database,
> so you should start to see this problem go away (and new ones arise).
>

What is the extent of deployment and use of URET?

> Can you shed any light on the rules for including fixes from adjacent
> centers? Is it everything within 200 nm of the center boundary? Or just
> airway VORs?

Unfortunately, I do not know the exact rules they use for determining
what fixes to include. Something like ORD is in everyone's computer.
Something like 7Y7 is only known by Minneapolis' computers. As far as
anything in between, well, I could only guess....


> What does the computer do if it cannot process fixes to determine the route?

It free tracks, which means it'll predict your future position based
only on your history. This makes route lines not work, auto-handoffs
disabled, conflict alert inaccurate, etc. You won't find an aircraft
get into that state, though. The controller will fix it at least to
one fix outside his center so you will always stay in flat track: or
predicting your future based on your history AND your flight plan
informaiton.


> What is the extent of deployment and use of URET?

I don't have a map offhand, but they showed it to us when we went
through the training, so I'm going on my memory. Most of the eastern
centers have it now. Atlanta has not gotten it for political issues.
Chicago has it but they set so many rules about its use that the
controllers are ignoring it.
I know definitely Boston, Cleveland, Minneapolis, Kansas City, and
Denver have it. Some of the others do, too, but again, I don't have a
map here. The controllers at these ceters for the most part love it.
It's slowly working its way west. Denver got it this summer, not sure
about Houston or Dallas. Salt Lake is next in line, but I think they
are delayed until after DRVSM (domestic reduced vertical separation
minimum) is deployed nationwide in January.

TJ Girl

Stan Prevost wrote:

>
> The first thing is to understand the controller's needs for route
> definition, specifically for a direct flight for this discussion. One might
> expect that the controller would be concerned only with the route through
> his airspace, so he couldn't care less about the route definition way down
> the line. Does he need to be able to make my course line appear on his
> radar scope all the way through his airspace?

Course line? What course line?



Or does he just need a
> short-term projection of my track using radar for present position,
> direction, and speed?

Ain't got that either.


Probably one need is to be prepared to handle radar
> failure.

Yeah, right. If the radar fails completely at a busy terminal airspace
you're screwed. We all are. The controller will attempt to knock the
cobwebs off his long unused nonradar procedures but the reality is
traffic comes to a grinding halt.


In nonradar procedures, I think they try to move us all onto
> airways, and to do this, the panicked controller needs to know which airways
> to move us onto that keep us going in the proper general direction and out
> of his airspace (or maybe the computers suggest new airway routing).

In a suprise nonradar situation I would call the center to see if a
flight on a direct clearance is in radar contact. If so then he can
stay on his direct route. But this being Salt Lake Center they don't
much care if an aircraft is in radar contact so the aircraft would most
likely stay on his direct route.


So how
> does knowing one VOR-based fix in his airspace do that?

I have a map.


Does he have his
> computer draw a line on his scope from present position through the fix, so
> that he can then pick airways that approximate that route?

You don't go making up airways. In this situation you would give a guy
a heading to join an airway and reclear him via that airway. Separation
would instantly go 100% vertical, it's the easiest one to apply.



>
> But eventually, no matter how well we understand those things, we will come
> back to the old oft-debated issue of no matter what you file, you will get
> something different or will get major reroutes, so you might as well file
> direct airport to airport.


99.9% of IFR flights out of Billings are as filed, so this is going to
depend on where you are.



I am sure this is more true in some areas than
> others, based on my own experience, and for frequently-flown routes, one can
> eventually learn reliable routing. Up through the northeast corridor, I
> always get reroutes. In the east-central US, I can file from Alabama to
> northern Lower Michigan airport-to-airport direct and always get cleared as
> filed with no reroutes. I do this frequently. Many times, flying to other
> destinations, I have tried to tweak my route to include some major VORs,
> only to get an in-flight clearance direct to destination airport.

Minneapoils and Salt Lake give a lot of direct and vector to direct
clearances.



>>Now if you've filed airway routing, I'm told an unrecognized
>>intersection or waypoint at the end of the route is no big deal.
>>The flight plan gets processed to the unrecognized point. The first
>>controller will know which way you're going, and by the time it
>>matters, the ATC computer will recognize it. Which is why Don Brown
>>and some others favor airway routing, and I have to say I'm
>>coming around to that viewpoint myself.

Airway routing is necessary in really busy airspace because right now we
have no better, more efficient way of doing things. Get out into the
other 75% of the country and direct routings are the norm.


>
> I don't see any difference between filing airport-IAF-airport vs
> airport-airport, in terms of fix recognition and controllers knowing your
> route. If the IAF (or other nearby fix) is there, it likely won't be
> recognized by a distant computer (another center's airspace). But neither
> will the airport. Maybe some airports are in all computers, but going into
> Podunksville Muni, forget it. "N8158Y, say on-course heading." (Having
> lat/long in the flight plan for the final enroute fix or for the destination
> doesn't seem to change getting the heading request.) In either case, at the
> originating end and along the way, the controllers will be in the dark about
> your route, but the situation resolves itself as the flight nears its
> destination.

You also need to understand what I see as an approach controller. The
strip that prints out of your arriving flight does not have your cleared
route on it. All it has is the destination airport and the time you
will be there. I don't need to know or even care what you filed or were
cleared for. You're landing here and you will be vectored as such.

Stan Prevost wrote:


>
> Another theme running through the previous comments is that the computer at
> each ATC facility along the route does some kind of processing on the flight
> plan, but upon encountering a fix that is not in its database, will "stop
> processing" at the last recognized fix. This supposedly results in somehow
> bollixing up the works.

No such thing happens. If the strip prints out of the computer it will
work for the entire route. There is never a point where the computer
throws up its arms and says screw it, where some action is required by
the controller to keep the flight active.


I think it is being said that the controller will
> be unable to determine the route of flight through his/her airspace,

That can happen if you file direct and the controller doesn't recognize
the destination airport. However the only controller that may really be
in the dark is the first one because in all subsequent sectors the plane
is on a straight line to his destination. You may not know where that
is but you know about where it is because he is going directly there.


>
> Well, I really don't understand. First, I don't know what kind of
> "processing" is performed by the ATC computers, and I don't know what is
> meant by "stops processing" or "rejected".

It means nothing because it doesn't happen on an active flight plan. If
I try to make an ammendment and the computer doesn't recognize the fix
then it will just reject the ammendment but the original active flight
plan remains in effect.


When the computer *successfully*
> processes the plan, what is different from what happens when it "stops
> processing" at some point?

It doesn't, don't worry about it.




Why is it not the same
> situation with just GPS airport-to-airport direct, with no enroute fixes?
> Do all the computers store all the airports?

No. My computer stores the airports in my center and some big airports
in the other centers.


I know that when I file direct
> to Podunksville Muni several centers away, nobody along the route seems to
> have any idea where that airport is, but nothing is bollixed up.

Exactly. If your flight plan was originally accepted by AFSS or DUATS
then it will work along your entire route.



>
> It would be useful to know more about the capability of center and approach
> control computers in terms of their databases of fixes.

The approach controls don't have their own computer databases of fixes.
Everything runs by modem thru the center computer.

because Newps says they "fix" those kind of
> flight plans when they see them,

We offer to get rid of the garbage in the flight plan. Sometimes they
want to keep it in there for training but most of the time they are
happy to just go direct airport to airport.



>
> Any help in getting this sorted out and understood will be appreciated.

Now, go to your nearest TRACON and get a tour. Then ask the controller
to file some flight plans thru his FDIO and you will get a better
understanding and you will see the computer accept some routings and
reject others.

"Newps" > wrote in message
...
>
> If the computer doesn't recognize a fix it won't accept it.
>

True only if the fix is within the processing center or the first fix
outside.


>
> To make matters even more confusing you can call AFSS and get a
> plan into the computer that my computer will not take.
>

No, he can't.


>
> And my computer will print that flight plan and it will work normally.
>

No, it won't.


>
> For example when I fly back
> to the Minneapolis area I always land at Anoka County, ANE. You can
> call Great Falls AFSS(or use DUATS) and file your flight plan to ANE and
> it will print out in front of me. I, however, cannot type in the same
> flight plan because my computer does not recognize ANE.
>

Wrong. What the computer accepts or rejects does not vary with the source
of the flight plan.

"Stan Prevost" > wrote in message
...
>
> OK, so all the concerns about an IAF or other waypoint not being
recognized
> by ATC computers will not result in the pilot being surprised by a
clearance
> that does not include the waypoint. The biggest surprise would be to a
> pilot air-filing and the controller, like you, reporting back that the
> computer does not recognize one waypoint on the route attempting to be
> filed. Then Plan B would have to be formulated, but this is still early
in
> the game.
>

Easily remedied. Just include a good fix outside the originating Center on
or near the desired route. If you can provide the coordinates of the
offending fix they can be entered just prior to it. The flight plan will
then process just fine and no alteration of your route is needed at all.